home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1180 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.3 KB
  1. From: David Brownell <brownell@ix.netcom.com>
  2. Message-ID: <31795159.766F@ix.netcom.com>
  3. X-Original-Date: Sat, 20 Apr 1996 14:04:25 -0700
  4. Path: in1.uu.net!bounce-back
  5. Date: 21 Apr 96 06:50:19 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.programming.threads,comp.std.c++
  8. Subject: Re: Is C++ STL MT-Safe?
  9. Organization: Dave's VAX
  10. References: <4kmjvj$89t@usc.edu> <4kspmb$9tb@ubszh.fh.zh.ubs.com> <3173E95E.5AC@ix.netcom.com> <4l12rf$q11@galaxy.ucr.edu> <31753C02.58A6@ix.netcom.com> <3175B960.3BCAE17D@cantrip.org>
  11. X-Netcom-Date: Sat Apr 20  4:05:26 PM CDT 1996
  12. X-Mailer: Mozilla 2.0 (Win95; I)
  13. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  14.     iQBFAgUBMXna7+EDnX0m9pzZAQFdbgF/R3y71N9bu033MQHN8ZDrz5pW4gms57h8
  15.     yBerZ5c1cCT2EFNK/wrZBYQ40UQbpgE9
  16.     =2Ysu
  17.  
  18. Nathan Myers <http://www.cantrip.org/> wrote:
  19. > 
  20. > David Brownell wrote:
  21. > >
  22. > > Tom Payne wrote:
  23. > > > Is there agreement on what is meant by the term "thread safe."  (I have
  24. > > > seen definitions that seemed quite inadequate.)
  25. > >
  26. > > IMHO "Thread-safe" is a misleading goal.  You actually want an API that's
  27. > > natural to use in a threaded environment ... in some cases, that means an
  28. > > API that's OK to use from concurrent threads (e.g. add to containers),
  29. > > but in other cases it's reasonable to have objects that are only usable
  30. > > from a single thread (e.g. iterators).
  31. > 
  32. > In this sense, STL (and the whole std library) is already MT-safe.
  33.  
  34. I disagree ... "the whole std library" isn't "natural" to use,
  35. minimally since iostreams don't provide the analogue of stdio
  36. flockfile().  Programmers have to invent their own synchronization; you
  37. don't have the guarantees C programmers have.  Namely, that code like
  38. this will not interleave output from two threads except between chunks
  39. of fully formatted data:
  40.  
  41.     flockfile (stdout);
  42.     /* many calls to emit a chunk of formatted data ... */
  43.     putc, putc, putc, printf, puts, putc, putc, printf, ...
  44.     funlockfile (stdout);
  45.  
  46. Currently, the C++ library interfaces don't provide primitives to
  47. synchronize use of the library objects by different threads.  It's
  48. _very_ natural to expect the library to define such a convention.  If
  49. the standard library doesn't include one, there will be many -- and the
  50. different conventions won't interoperate, so new kinds of bugs will
  51. have found a good home.
  52.  
  53. This issue applies to STL as well as to iostreams.  Containers are
  54. often used by multiple threads, so would benefit from shared/exclusive
  55. (read/write) locking being available with standardized templates.
  56. There are interactions with iterators too:  most iterators will want a
  57. stable "snapshot" view (as in single-threaded code) without preventing
  58. other threads from using the container concurrently.
  59.  
  60.  
  61. > Of course this depends on it being implemented properly, but there are
  62. > no interfaces in the standard C++ library that cry out for "_r" versions,
  63. > as were found in the C library.  This is not accidental.
  64.  
  65. I hope you're right about this, but keep in mind that defining
  66. interfaces that don't use "global" state (and so don't need "_r"
  67. versions) is only one part of the interface definition problem.
  68. Providing synchronization support is another part of the problem, as is
  69. resolving performance issues that can sometimes be created due to lock
  70. contention.  And let's not forget nailing down any locking hierarchy
  71. rules to be followed by subclassers!
  72.  
  73.  
  74. > This is not to say that the STL containers can be shared between threads
  75. > without some kind of synchronization.
  76.  
  77. With respect to STL one might make the same argument Booch made (as I
  78. recall) when he first did his generic components in Ada:  policy
  79. flexibility is needed.
  80.  
  81. Today's STL components require external synchronization, which is one
  82. policy.  But that really doesn't help in common scenarios such as
  83. threads sharing containers and the resources they hold.  From where I
  84. sit, it's more useful to have those (often) tricky MT algorithms made
  85. generic than to have the same thing done with simple linked list
  86. algorithms.
  87. -- 
  88. David Brownell
  89. http://www.netcom.com/~brownell
  90. ---
  91. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  92. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  93. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  94. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  95. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  96.